1. Technical Field
This disclosure relates generally to switching traces modes, and more specifically, to switching traces modes without halting a processor.
2. Description of the Related Art
Developers of processors and/or applications usually need to have access to a basic set of development tool functions in order to accomplish their jobs. For run-control, a developer typically needs to query and modify when a processor is halted, showing all locations available in a supervisor map of the processor. Moreover, a developer also usually needs support for breakpoint/watchpoint features in debuggers, either as hardware or software breakpoints depending on the architecture. For logic analysis, a developer usually needs to access instruction trace information. A developer typically needs to be able to interrogate and correlate instruction flow to real-world interactions. A developer also usually needs to retrieve information on how data flows through the system and to understand what system resources are creating and accessing data. Additionally, a developer usually needs to assess whether embedded software is meeting a required performance level.
The Nexus 5001 Forum (formerly known as the global embedded processor debug interface standard consortium (GEPDISC)) was formed to develop an embedded debug/trace interface standard (the “Nexus standard”) for embedded control applications. The Nexus standard is particularly applicable to the development of automotive powertrains, data communication equipment, embedded systems, computer peripherals, wireless systems, and other control applications. The Nexus standard provides a specification and guidelines for implementing various messages, e.g., program trace messages (such as branch history messages and synchronization messages), data trace messages, and task/process identification messages (such as ownership trace messages), that may be utilized in debugging applications while minimally impacting operation of a system under development/test.
As defined by the Nexus standard, a program trace message is a message that is provided in response to a change of program flow, and the Nexus standard requires a system under development or test to be halted when changing program trace modes. This may not allow for analysis and/or debugging of a system under development and/or under test that is running in scenarios where a change of a program trace mode is needed or desired. For example, the system under development and/or under test can include and/or can be coupled to one or more peripherals that may not halt when the system under development and/or under test is halted. In one instance, data from the one or more peripherals can be lost or corrupted while the system under development and/or under test is halted to switch program trace modes. In another instance, one or more peripherals may consume data that is provided by the system under development and/or under test, and the one or more peripherals that consume data, provided by the system under development and/or under test, may malfunction and/or provide erroneous data during and/or after the system under development and/or under test is halted to switch program trace modes.